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PPP Gandalf FZA Compression Protocol 


Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard. Distribution of this memo is 
unlimited. 

Abstract 


The Point-to-Point Protocol (PPP) [1] provides a standard method for 
transporting multi-protocol datagrams over point-to-point links. 


The PPP Compression Control Protocol [2] provides a method to 
negotiate and utilize compression protocols over PPP encapsulated 
links. 


This document describes the use of the Gandalf FZA data compression 
algorithm [3] for compressing PPP encapsulated packets. 
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1. Introduction 


FZA is a high performance LZ [4] derivative that maximizes 
compression at the expense of memory and CPU. Compression 
performance can be adjusted based on CPU and memory available. 


Multiple PPP packets can be combined in a single compressed frame, or 
a single PPP packet can be spread across multiple frames. 


1.1. Licensing 
Source and object licenses are available on a non-discriminatory 


basis for either a royalty or fixed price arrangement. Patent 
indemnity is included with the license. 
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2s 


FZA Packets 


Before any FZA packets may be communicated, PPP must reach the 
Network-Layer Protocol phase. 


When the Compression Control Protocol (CCP) has reached the Opened 
state, and FZA is negotiated as the primary compression algorithm, 
the PPP Protocol field indicates type hex OOFB (link compressed 
datagram), or type hex OOFD (compressed datagram). 


The maximum length of the FZA datagram transmitted over a PPP link is 
the same as the maximum length of the Information field of a PPP 
encapsulated packet. 
Padding 
The FZA packets require the negotiation of the Self-Describing- 
Padding Configuration Option [5] at LCP Link Establishment. 
Reliability and Sequencing 
The FZA algorithm expects a reliable link, as described in "PPP 
Reliable Transmission" [6]. 
FZA expects the packets to be delivered in sequence. 
Data Expansion 
The maximum expansion of Gandalf FZA is 2:1. However, typical 
expansion on pre-compressed data is 1.01:1. Expanded data is sent 


to maintain the integrity of the compression history. 


When the expansion exceeds the size of the peer's Maximum Receive 


Unit for the link, the expanded packet is sent in multiple PPP 


frames. The compressed data contains an indication of the end of 


the original packet. 
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2.1. Packet Format 


A summary of the Gandalf FZA packet format is shown below. The 
fields are transmitted from left to right. 


(—————R——————————————O——————— M: 
| PPP Protocol Compressed Data 
——————R————————————5^^———————————— EG 


PPP Protocol 


One or two octets. The PPP Protocol field is described in the 
Point-to-Point Protocol Encapsulation [1]. 


Type 00FD is used when the PPP multilink protocol is not used, 
and/or "inside" a multilink bundle. Type OOFB is used "outside" 
multilink, to compress independently on individual links of a 
multilink bundle. This value MAY be compressed when LCP 
Protocol-Field-Compression is negotiated. 


Compressed Data 
One or more octets. The compressed PPP encapsulated packet (s). 
Prior to compression, the uncompressed data begins with the 
original PPP Protocol number. This value MAY be compressed when 
LCP Protocol-Field-Compression is negotiated. 
The original Protocol number is followed by the original 
Information field. The length of the original Information field 
before compression MUST NOT exceed the link Maximum Receive Unit 


(MRU). 


PPP Link Control Protocol packets MUST NOT be sent within 
compressed data. 
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3. Configuration Option Format 
Description 
The CCP Gandalf-FZA Configuration Option negotiates the use of 
Gandalf FZA on the link. By default or ultimate disagreement, no 


compression is used. 


A summary of the Gandalf-FZA Configuration Option format is shown 
below. The fields are transmitted from left to right. 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | History | Version 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 


T9 


History 
One octet. The History field specifies the maximum size of the 
compression history in powers of 2. Valid values range from 12 to 
15. 


The peer is not required to send as many histories as the 
implementation indicates that it can accept. 


Version 
Zero or more octets of additional configuration information. Any 
implementation that does not implement this information MUST send 
a Configure-Nak without this field. 
The Version field is not present for FZA. 
The Version field is a single octet containing the value 1 for 
FZA+. 


Security Considerations 


Security issues are not discussed in this memo. 
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